SharePoint 2010 : Adding a user via PowerShell, Delegating PowerShell permissions

1. Adding a user via PowerShell

When SharePoint is initially set up, many users may need to be added to SharePoint groups for a new site. The quickest and most efficient way to accomplish this is through PowerShell and scripting.

The following recipe shows how to add a user to a SharePoint group via PowerShell.

Getting ready

The user must have access to one of the servers running PowerShell 2.0 and be a member of the WSS_ADMIN_WPG on the local computer. You must also be a member of the SharePoint_Shell_Access role&; on the configuration database (SQL Role).

There must be an existing site, a SharePoint group called TestAddUser, and a user named jdoe set up in the active directory.

How to do it...

How it works...

Using PowerShell with SharePoint, the Microsoft.SharePoint.PowerShell snapin must be added using the Add-PSSnapin cmdlet&;. This is done automatically when you use the SharePoint 2010 Management Shell.

PowerShell is integrated with the .NET framework. SharePoint exposes its management capability to PowerShell. The SharePoint object model is also available via PowerShell. The power of PowerShell is the ability to script commands together. These commands are referred to as cmdlets.

Cmdlets follow a <verb> <noun> naming pattern&;.

There's more...

The following PowerShell commands provide users with management functionality:

• Get-SPUser&;: Returns a user after matching the record with the provided criteria. The common criteria are user identity and website where they are a user.

• Remove-SPUser: Deletes a user from a site.&;

• Move-SPUser: Moves a user account into the provided site.

• Set-SPUser: Configuration of user properties.

More info

You can combine several cmdlets together to create a script, saving the file with a .ps1 extension. The script could reference a file containing a list of active directory user accounts. This will allow you to do a batch upload of the users to the designated sites and groups.

2. Delegating PowerShell permissions

One of the many promises SharePoint 2010 delivers on is the empowering of users. In other words, SharePoint 2010 allows an administrator to delegate responsibility down to the other administrative user. The concern with doing this is exposing other administrative tasks. Just because someone can manage an application, such as Search, does not mean they should be able to manage other service applications. SharePoint 2010 handles this without putting at risk the security of the other components. Farm Administrators can designate users to manage their own service application. This is done through the management UI of each service application. Taking this management one step further, a Farm Administrator can designate a user with the ability to run PowerShell commands against their particular service(s) from their own machines.

The least privileged account model in SharePoint has been taken to another level. Users have access to manage only what you, as an administrator, have designated to them.

This recipe will show how to grant PowerShell access to a user so that they can manage their service applications.

Getting ready

You must have farm-level administrative permissions. A user must be set up in the active directory — the recipe will use the domain \jdoe. Replace domain with the appropriate value from your installation.

You will need the name of the service application database to which you are assigning rights. You can get this with the help of the following PowerShell command:

GetSPServiceApplication-SPServiceApplication

How to do it...

How it works...

The first command did the following two things:

• It added the user to the SharePoint_Shell_Access role&; in the farm configuration database. If the role was not in the database, it is created automatically. When the user is added, the role grants the users, db_owner as well as securityadmin, with the rights to the farm configuration database.

• It added the user to the WSS_ADMIN_WPG local security group&; on each server in the farm.

The second command added the parameter named database. We targeted a specific content database (using its GUID in this case) and the user was added to the SharePoint_Shell_Access role for that database. Additionally, the user is added to the role in the Central Administration content database.

There's more...

Using PowerShell, an administrator can obtain a list of names that are part of the SharePoint_Shell_Access role&;, with the help of the following command:

Get-SPShellAdmin

More info

The most effective use of PowerShell is in regards to scripting. Actions can be automated. Automation comes in the guise of writing code. Combine this statement with the type of access that is granted in this recipe — db_owner. This should not be granted without any thought, for example, power users should not be conferred with so much authority.

A typical power user cannot write, and should not be authorized to write code, in order to automate things such as uploading a Term Set to the managed metadata service. On top of that, a power user should not be granted the db_owner access as is shown in this recipe.

Note that PowerShell does not do security trimming. When a user is given this ability on a database, they have db_owner access to everything in that database.

However, the administrator of the farm may not have time to automate functions. A Farm Administrator can delegate this responsibility to the appropriate person who has the ability to write the PowerShell code. That person can be granted ownership of the service.